Definition of low-level security rules in terms of high-level security concepts

ABSTRACT

A set of pluggable rules are used to define low-level security rules in terms of high-level security concepts. The rules are part of a pluggable module that can interact with a business logic to provide different granularities of control.

TECHNICAL FIELD

[0001] The present invention is directed to security, and moreparticularly to defining low-level security rules in terms of high-levelsecurity concepts.

BACKGROUND

[0002] Computer programs are traditionally developed by the writing ofsource code for components of the program that include a main module andvarious other modules functions, or subroutines that are invoked by themain module. The source code of components of computer programs aretypically developed specifically for the domain of one computer program.As a result, one computer program might not be able to use componentsdeveloped specifically for another computer program. Although someutility components (e.g., sort routines) can be reused by differentcomputer programs, they are typically very low-level components that arenot related to the domain of the computer program. Because of theinability to reuse high-level components for multiple computer programs,the cost of developing a computer program can be quite high. Inaddition, because the components are new, their reliability is unproved.

[0003] Many techniques have been developed to facilitate the reusabilityand reliability of software components. One well-known technique isobject-oriented programming. Object-oriented programming allows aprogrammer to define a type of component, known as an “object.” Eachtype of object has a defined interface with a defined behavior. Aprogrammer can develop a computer program to use the interfaces ofobjects that have been developed by other programmers to provide thatbehavior within the computer program. The behavior of an object isprovided by methods (or member functions), and the data of an object isprovided as attributes (or data members). Some object-orientedprogramming languages allow attributes to be set and retrieved directly(e.g., “object.attribute1=15”), while other object-oriented programminglanguages only allow attributes to be set and retrieved indirectlythrough methods (e.g., “object.setAttribute1(15)”). The methods forsetting attributes are referred to as “set methods” and for retrievingattributes are referred to as “get methods.”

[0004] Although object-oriented programming techniques have helpedincrease the reusability and reliability software components, it isstill very expensive to develop a computer program even using thesereusable components. Part of the expense is attributable to the need ofa computer programmer to know and understand all the interfaces of thecomponents in order to integrate the components into the desiredcomputer program. It would be desirable to have a programming techniquethat would increase reusability and reliability of the softwarecomponents while reducing the overall expense of developing computerprograms.

[0005] One specific situation where problems arise is in securityenforcement. Security is important in a wide variety of types ofprograms, such as access to items in a database—the program designer maywant to assign different security access to different users of anddifferent items in the database. One solution to providing securityenforcement is to implement a fixed security scheme in which fixed rulesare added to the program to limit access as desired. However, such fixedrules can be difficult to change and do not easily port over to otherprograms. Another solution is to implement the security enforcement inthe underlying component being accessed (e.g., a database). However,this solution suffers from the same problem of being difficult to changeand not easily ported over to other programs.

[0006] Thus, a need remains for a security enforcement technique thatallows for easier changing of the security to accommodate differentenvironments (e.g., databases storing different types of information oritems) as well as to be able to easily apply the security enforcement todifferent programs with reduced overall expense.

SUMMARY

[0007] Definition of low-level security rules in terms of high-levelsecurity concepts is described herein.

[0008] A set of pluggable rules are used to define low-level securityrules in terms of high-level security concepts. The rules are part of apluggable module that can interact with a business logic to providedifferent granularities of control.

BRIEF DESCRIPTION OF THE DRAWINGS

[0009]FIG. 1 illustrates a network system that implements a serverapplication architecture that may be tailored to various domains.

[0010]FIG. 2 is a block diagram of the application architecture.

[0011]FIG. 3 is a flow diagram illustrating a general operation of theapplication architecture when handling client requests.

[0012]FIG. 4 is a block diagram of an exemplary execution modelconfigured as an asset catalog program and a controller to executevarious interactions of the asset catalog program.

[0013]FIG. 5 is a flow diagram of a process for executing the assetcatalog program.

[0014]FIG. 6 is a block diagram of the program controller used in theexecution model of FIG. 4.

[0015]FIG. 7 is a block diagram of a security policy enforcement module.

[0016]FIG. 8 illustrates an exemplary method of expressing securityrules.

[0017]FIG. 9 is a flow diagram illustrating the operation of thesecurity policy enforcement module.

[0018] The same reference numbers are used throughout the figures toreference like components and features.

DETAILED DESCRIPTION

[0019] A software architecture specifies distinct layers or modules thatinteract with each other according to a well-defined specification tofacilitate efficient and timely construction of business processes andserver applications for many diverse domains. Examples of possibledomains include asset management, leasing and lending, insurance,financial management, asset repair, inventory tracking, otherbusiness-oriented domains, and so forth. The architecture implements acommon infrastructure and problem-solving logic model using a domainframework. By partitioning the software into a hierarchy of layers,individual modules may be readily “swapped out” and replaced by othermodules that effectively adapt the architecture to different domains.

[0020] With this architecture, developers are able to create differentsoftware applications very rapidly by leveraging the commoninfrastructure. New business models can be addressed, for example, bycreating new domain frameworks that “plug” into the architecture. Thisallows developers to modify only a portion of the architecture toconstruct new applications, resulting in a fraction of the effort thatwould be needed to build entirely new applications if all elements ofthe application were to be constructed.

[0021] Exemplary System

[0022]FIG. 1 shows a network system 100 in which the tiered softwarearchitecture may be implemented. The system 100 includes multipleclients 102(1), 102(2), 102(3), . . . , 102(N) that submit requests viaone or more networks 104 to an application server system 106. Uponreceiving the requests, the server system 106 processes the requests andreturns replies to the clients 102 over the network(s) 104. In somesituations, the server system 106 may access one or more resources108(1), 108(2), . . . , 108(M) to assist in preparing the replies.

[0023] The clients 102 may be implemented in a number of ways, includingas personal computers (e.g., desktop, laptop, palmtop, etc.),communications devices, personal digital assistants (PDAs),entertainment devices (e.g., Web-enabled televisions, gaming consoles,etc.), other servers, and so forth. The clients 102 submit theirrequests using a number of different formats and protocols, dependingupon the type of client and the network 104 interfacing a client and theserver 106.

[0024] The network 104 may be implemented by one or more different typesof networks (e.g., Internet, local area network, wide area network,telephone, etc.), including wire-based technologies (e.g., telephoneline, cable, etc.) and/or wireless technologies (e.g., RF, cellular,microwave, IR, wireless personal area network, etc.). The network 104can be configured to support any number of different protocols,including HTTP (HyperText Transport Protocol), TCP/IP (TransmissionControl Protocol/Internet Protocol), WAP (Wireless ApplicationProtocol), and so on.

[0025] The server system 106 implements a multi-layer softwarearchitecture 110 that is tailored to various problem domains, such asasset management domains, financial domains, asset lending domains,insurance domains, and so forth. The multi-layer architecture 110resides and executes on one or more computers, as represented by servercomputers 112(1), 112(2), 112(3), . . . , 112(S). The tieredarchitecture 110 may be adapted to handle many different types of clientdevices 102, as well as new types as they become available.Additionally, the architecture 110 may be readily configured toaccommodate new or different resources 108.

[0026] The server computers 112 are configured as general computingdevices having processing units, one or more types of memory (e.g., RAM,ROM, disk, RAID storage, etc.), input and output devices, and a busingarchitecture to interconnect the components. As one possibleimplementation, the servers 112 may be interconnected via other internalnetworks to form clusters or a server farm, wherein different sets ofservers support different layers or modules of the architecture 110. Theservers may or may not reside within a similar location, with thesoftware being distributed across the various machines. Various layersof the architecture 110 may be executed on one or more servers. As analternative implementation, the architecture 110 may be implemented onsingle computer, such as a mainframe computer or a powerful servercomputer, rather than the multiple servers as illustrated.

[0027] The resources 108 are representative of any number of differenttypes of resources. Examples of resources include databases, websites,legacy financial systems, electronic trading networks, auction sites,and so forth. The resources 108 may reside with the server system 106,or be located remotely. Access to the resources may be supported by anynumber of different technologies, networks, protocols, and the like.

[0028] General Architecture

[0029]FIG. 2 illustrates one exemplary implementation of the multi-layerarchitecture 110 that is configured as a server application for abusiness-oriented domain. The architecture is logically partitioned intomultiple layers to promote flexibility in adapting the architecture todifferent problem domains. Generally, the architecture 110 includes anexecution environment layer 202, a business logic layer 204, a datacoordination layer 206, a data abstraction layer 208, a service layer210, and a presentation layer 212. The layers are illustrated verticallyto convey an understanding as to how requests are received and handledby the various layers.

[0030] Client requests are received at the execution environment 202 andpassed to the business logic layer 204 for processing according to thespecific business application. As the business logic layer 204 desiresinformation to fulfill the requests, the data coordination layer 206,data abstraction layer 208, and service layer 210 facilitate extractionof the information from the external resources 108. When a reply iscompleted, it is passed to the execution environment 202 andpresentation layer 212 for serving back to the requesting client.

[0031] The architecture 110 can be readily modified to (1) implementdifferent applications for different domains by plugging in theappropriate business logic in the business logic layer 204, (2) supportdifferent client devices by configuring suitable modules in theexecution environment 202 and presentation layer 212, and (3) extractinformation from diverse resources by inserting the appropriate modulesin the data abstraction layer 208 and service layer 210. The partitionednature of the architecture allows these modifications to be madeindependently of one another. As a result, the architecture 110 can beadapted to many different domains by interchanging one or more modulesin selected layers without having to reconstruct entire applicationsolutions for those different domains.

[0032] The execution environment 202 contains an executioninfrastructure to handle requests from clients. In one sense, theexecution environment acts as a container into which the business logiclayer 204 may be inserted. The execution environment 202 provides theinterfacing between the client devices and the business logic layer 204so that the business logic layer 204 need not understand how tocommunicate directly with the client devices.

[0033] The execution environment 202 includes a framework 220 thatreceives the client requests and routes the requests to the appropriatebusiness logic for processing. After the business logic generatesreplies, the framework 220 interacts with the presentation layer 212 toprepare the replies for return to the clients in a format and protocolsuitable for presentation on the clients.

[0034] The framework 220 is composed of a model dispatcher 222 and arequest dispatcher 224. The model dispatcher 222 routes client requeststo the appropriate business logic in the business logic layer 204. Itmay include a translator 226 to translate the requests into anappropriate form to be processed by the business logic. For instance,the translator 226 may extract data or other information from therequests and pass in this raw data to the business logic layer 204 forprocessing. The request dispatcher 224 formulates the replies in a waythat can be sent and presented at the client. Notice that the requestdispatcher is illustrated as bridging the execution environment 202 andthe presentation layer 212 to convey the understanding that, in thedescribed implementation, the execution environment and the presentationlayer share in the tasks of structuring replies for return andpresentation at the clients.

[0035] One or more adapters 228 may be included in the executionenvironment layer 202 to interface the framework 220 with various clienttypes. As an example, one adapter may be provided to receive requestsfrom a communications device using WAP, while another adapter may beconfigured to receive requests from a client browser using HTTP, while athird adapter is configured to receive requests from a messaging serviceusing a messaging protocol.

[0036] The business logic layer 204 contains the business logic of anapplication that processes client requests. Generally speaking, thebusiness logic layer contains problem-solving logic that producessolutions for a particular problem domain. In this example, the problemdomain is a commerce-oriented problem domain (e.g., asset lending, assetmanagement, insurance, etc.), although the architecture 110 can beimplemented in non-business contexts. The logic in the logic layer istherefore application-specific and hence, is written on aper-application basis for a given domain.

[0037] In the illustrated implementation, the business logic in thebusiness logic layer 204 is constructed as one or more execution models230 that define how computer programs process the client requestsreceived by the application. The execution models 230 may be constructedin a variety of ways. One exemplary execution model employs aninteraction-based definition in which computer programs are individuallydefined by a series of one or more interaction definitions based on arequest-response model. Each interaction definition includes one or morecommand definitions and view definitions. A command definition defines acommand whose functionality may be represented by an object that hasvarious attributes and that provides the behavior for that command. Aview definition defines a view that provides a response to a request.

[0038] One example of an interaction-based model is a command bean modelthat employs multiple discrete program modules, called “Command Beans”,that are called for and executed. The command bean model is based on the“Java Bean” from Sun Microsystems, which utilizes discrete Java™ programmodules. One particular execution model 230 that implements an exemplaryprogram is described below beneath the heading “Business Logic Layer”with reference to FIGS. 4-6.

[0039] Other examples of an execution model include an action-view modeland a use case model. The action-view model employs action handlers thatexecute code and provide a rendering to be served back to the client.The use case model maps requests to predefined UML (Unified ModelingLanguage) cases for processing.

[0040] The data coordination layer 206 provides an interface for thebusiness logic layer 204 to communicate with a specific domain framework250 implemented in the data abstraction layer 208 for a specific problemdomain. In one implementation, the framework 250 utilizes a domainobject model to model information flow for the problem domain. The datacoordination layer 206 effectively partitions the business logic layer204 from detailed knowledge of the domain object model as well as anyunderstanding regarding how to obtain data from the external resources.

[0041] The data coordination layer 206 includes a set of one or moreapplication data managers 240, utilities 242, and framework extensions244. The application data managers 240 interface the particular domainobject model in the data abstraction layer 208 into a particularapplication solution space of the business logic layer 204. Due to thepartitioning, the execution models 230 in the business logic layer 204are able to make calls to the application data managers 240 for specificinformation, without having any knowledge of the underlying domain orresources. The application data managers 240 obtain the information fromthe data abstraction layer 208 and return it to the execution models230. The utilities 242 are a group of reusable, generic, and low-levelcode modules that developers may utilize to implement the interfaces orprovide rudimentary tools for the application data managers 240.

[0042] The data abstraction layer 208 maps the domain object model tothe various external resources 108. The data abstraction layer 208contains the domain framework 250 for mapping the business logic to aspecific problem domain, thereby partitioning the business applicationsand application managers from the underlying domain. In this manner, thedomain framework 250 imposes no application-specific semantics, since itis abstracted from the application model. The domain framework 250 alsodoes not dictate any functionality of services, as it can load any typeof functionality (e.g., Java™ classes, databases, etc.) and be used tointerface with third-party resources.

[0043] Extensions 244 to the domain framework 250 can be constructed tohelp interface the domain framework 250 to the application data managers240. The extensions can be standardized for use across multipledifferent applications, and collected into a library. As such, theextensions may be pluggable and removable as desired. The extensions 244may reside in either or both the data coordination layer 206 and thedata abstraction layer 208, as represented by the block 244 straddlingboth layers.

[0044] The data abstraction layer 208 further includes a persistencemanagement module 252 to manage data persistence in cooperation with theunderlying data storage resources, and a bulk data access module 254 tofacilitate access to data storage resources. Due to the partitionednature of the architecture 110, the data abstraction layer 208 isolatesthe business logic layer 204 and the data coordination layer 206 fromthe underlying resources 108, allowing such mechanisms from thepersistence management module 252 to be plugged into the architecture asdesired to support a certain type of resource without alteration to theexecution models 230 or application data managers 240.

[0045] A service layer 210 interfaces the data abstraction layer 208 andthe resources 108. The service layer 210 contains service softwaremodules for facilitating communication with specific underlyingresources. Examples of service software modules include a loggingservice, a configuration service, a serialization service, a databaseservice, and the like.

[0046] The presentation layer 212 contains the software elements thatpackage and deliver the replies to the clients. It handles such tasks aschoosing the content for a reply, selecting a data format, anddetermining a communication protocol. The presentation layer 212 alsoaddresses the “look and feel” of the application by tailoring repliesaccording to a brand and user-choice perspective. The presentation layer212 is partitioned from the business logic layer 204 of the application.By separating presentation aspects from request processing, thearchitecture 110 enables the application to selectively render outputbased on the types of receiving devices without having to modify thelogic source code at the business logic layer 204 for each new device.This allows a single application to provide output for many differentreceiving devices (e.g., web browsers, WAP devices, PDAs, etc.) and toadapt quickly to new devices that may be added in the future.

[0047] In this implementation, the presentation layer 212 is dividedinto two tiers: a presentation tier and a content rendering tier. Therequest dispatcher 224 implements the presentation tier. It selects anappropriate data type, encoding format, and protocol in which to outputthe content so that it can be carried over a network and rendered on theclient. The request dispatcher 224 is composed of an engine 262, whichresides at the framework 220 in the illustrated implementation, andmultiple request dispatcher types (RDTs) 264 that accommodate manydifferent data types, encoding formats, and protocols of the clients.Based on the client device, the engine 262 makes various decisionsrelating to presentation of content on the device. For example, theengine might select an appropriate data encoding format (e.g. HTML, XML,EDI, WML, etc.) for a particular client and an appropriate communicationprotocol (e.g. HTTP, Java™ RMI, CORBA, TCP/IP, etc.) to communicate theresponse to the client. The engine 262 might further decide how toconstruct the reply for visual appearance, such as selecting aparticular layout, branding, skin, color scheme, or other customizationbased on the properties of the application or user preference. Based onthese decisions, the engine 262 chooses one or more dispatcher types 264to structure the reply.

[0048] A content renderer 260 forms the content rendering tier of thepresentation layer 212. The renderer 260 performs any work related tooutputting the content to the user. For example, it may construct theoutput display to accommodate an actual width of the user's display,elect to display text rather than graphics, choose a particular font,adjust the font size, determine whether the content is printable or howit should be printed, elect to present audio content rather than videocontent, and so on.

[0049] With the presentation layer 212 partitioned from the executionenvironment 202, the architecture 110 supports receiving requests in oneformat type and returning replies in another format type. For example, auser on a browser-based client (e.g., desktop or laptop computer) maysubmit a request via HTTP and the reply to that request may be returnedto that user's PDA or wireless communications device using WAP.Additionally, by partitioning the presentation layer 212 from thebusiness logic layer 204, the presentation functionality can be modifiedindependently of the business logic to provide new or different ways toserve the content according to user preferences and client devicecapabilities.

[0050] The architecture 110 may include one or more other layers ormodules. One example is an authentication model 270 that performs thetasks of authenticating clients and/or users prior to processing anyrequests. Another example is a security policy enforcement module 280that supports the security of the application. The security enforcementmodule 280 can be implemented as one or more independent modules thatplug into the application framework to enforce essentially any type ofsecurity rules. New application security rules can be implemented bysimply plugging in a new system enforcement module 280 without modifyingother layers of the architecture 110.

[0051] General Operation

[0052]FIG. 3 shows an exemplary operation 300 of a business domainapplication constructed using the architecture 110 of FIGS. 1 and 2. Theoperation 300 is implemented as a software process of acts performed byexecution of software instructions. Accordingly, the blocks illustratedin FIG. 3 represent computer-readable instructions, that when executedat the server system 106, perform the acts stipulated in the blocks.

[0053] To aid the discussion, the operation will be described in thecontext of asset management, wherein the architecture 110 is configuredas a server application executing on the application server system 106for an asset management domain. Additionally, for discussion purposes,suppose a user is equipped with a portable wireless communicationsdevice (e.g., a cellular phone) having a small screen with limiteddisplay capabilities and utilizing WAP to send/receive messages over awireless cellular network. The user submits a request for information ona particular asset, such as the specification of a turbine engine or theavailability of an electric pump, from the wireless communicationsdevice.

[0054] At block 302, requests from various clients are received at theexecution environment layer 202. Depending on the client type, one ormore adapters 228 may be involved to receive the requests and convertthem to a form used internally by the application 110. In our example,the execution environment layer 202 receives the request from thewireless cellular network. An adapter 228 may be utilized to unwrap therequest from its WAP-based packet for internal processing.

[0055] At block 304, the execution framework 202 may pass the request,or data extracted from the request, to the authentication model 270 forauthentication of the client and/or user. If the requestor is not valid,the request is denied and a service denied message (or other type ofmessage) is returned to the client. Assuming the request is valid, theauthentication model 270 returns its approval.

[0056] At block 306, the model dispatcher 222 routes the request to oneor more execution models 230 in the business logic layer 204 to processthe client request. In our example, the model dispatcher 222 mightselect selects an execution model 230 to retrieve information on theparticular asset. A translator 226 may be invoked to assist inconforming the request to a form that is acceptable to the selectedexecution model.

[0057] At block 308, the execution model 230 begins processing therequest. Suppose, for example, that the selected execution model isimplemented as a command bean model in which individual code sequences,or “command beans”, perform discrete tasks. One discrete task might beto initiate a database transaction, while another discrete task might beto load information pertaining to an item in the database, and a thirddiscrete task might be to end the transaction and return the results.

[0058] The execution model 230 may or may not need to access informationmaintained at an external resource. For simple requests, such as aninitial logon page, the execution model 230 can prepare a reply withoutquerying the resources 108. This is represented by the “No ResourceAccess” branch in FIG. 3. For other requests, such as the examplerequest for data on a particular asset, the execution model may utilizeinformation stored at an external resource in its preparation of areply. This is illustrated by the “Resource Access” branch.

[0059] When the execution model 230 reaches a point where it wishes toobtain information from an external resource (e.g., getting assetspecific information from a database), the execution model calls anapplication data manager 240 in the data coordination layer 206 to querythe desired information (i.e., block 310). The application data manager240 communicates with the domain framework 250 in the data abstractionlayer 208, which in turn maps the query to the appropriate resource andfacilitates access to that resource via the service layer 210 (i.e.,block 312). In our example, the domain framework is configured with anasset management domain object model that controls information flow toexternal resources-storage systems, inventory systems, etc.—thatmaintain asset information.

[0060] At block 314, results are returned from the resource andtranslated at the domain framework 250 back into a raw form that can beprocessed by the execution model 230. Continuing the asset managementexample, a database resource may return specification or availabilitydata pertaining to the particular asset. This data may initially be in aformat used by the database resource. The domain framework 250 extractsthe raw data from the database-formatted results and passes that databack through the application data managers 240 to the execution model230. In this manner, the execution model 230 need not understand how tocommunicate with the various types of resources directly, nor understandthe formats employed by various resources.

[0061] At block 316, the execution model completes execution using thereturned data to produce a reply to the client request. In our example,the command bean model generates a reply containing the specification oravailability details pertaining to the requested asset. The executionmodel 230 passes the reply to the presentation layer 212 to bestructured in a form that is suitable for the requesting client.

[0062] At block 318, the presentation layer 212 selects an appropriateformat, data type, protocol, and so forth based on the capabilities ofthe client device, as well as user preferences. In the asset managementexample, the client device is a small wireless communication device thataccepts WAP-based messages. Accordingly, the presentation layer 212prepares a text reply that can be conveniently displayed on the smalldisplay and packages that reply in a format supported by WAP. At block320, the presentation layer 212 transmits the reply back to therequesting client using the wireless network.

[0063] Business Logic Layer

[0064] The business logic layer 204 contains one or more executionmodels that define how computer programs process client requestsreceived by the application. One exemplary execution model employs aninteraction-based definition in which computer programs are individuallydefined by a series of one or more interaction definitions based on arequest-response model. Each interaction definition includes commanddefinitions and view definitions. A command definition defines a commandwhose functionality may be represented by an object that has variousattributes and that provides the behavior for that command. A viewdefinition defines a view that provides a response to a request.

[0065] Each interaction of a computer program is associated with acertain type of request. When a request is received from the modeldispatcher 222, the associated interaction is identified to perform thebehavior of the commands defined by that interaction. The executionmodel automatically instantiates an object associated with each commanddefined in a command definition. Prior to performing the behavior of acommand, the execution model prepares the instantiated object byidentifying one or more input attributes of that object (e.g., byretrieving the class definition of the object) and setting the inputattributes (e.g., by invoking set methods) of the object based on thecurrent value of the attributes in an attribute store.

[0066] After setting the attribute values, the execution model performsthe behavior of the object (e.g., by invoking a perform method of theobject). After the behavior is performed, the execution model extractsthe output attributes of the object by retrieving the values of theoutput attributes (e.g., by invoking get methods of the object) andstoring those values in the attribute store. Thus, the attribute storestores the output attributes of each object that are then available toset the input attributes of other objects.

[0067] The execution model may serially perform the instantiation,preparation, performance, and extraction for each command.Alternatively, the execution of commands can be performed in paralleldepending on the data dependencies of the commands. Because theexecution model automatically prepares an object based on the currentvalues in the attribute store and extracts attribute values afterperforming the behavior of the object, a programmer does not need toexplicitly specify the invocation of methods of objects (e.g.,“object.setAttribute1=15”) when developing a computer program to beexecuted by the execution model.

[0068]FIG. 4 shows an exemplary execution model 230 configured for anasset catalog application that allows a user to view, create, and modifyinformation relating to assets (e.g., products) stored in an electroniccatalog. The model 230 includes an asset catalog program 402, anattribute store 404, and a program controller 406. The asset catalogprogram 402 includes eight interactions: login 410, do-login 412,main-menu 414, view-asset 416, create-asset 418, do-create-asset 420,modify-asset 422, and do-modify-asset 424. The controller 406 executesthe program 402 to perform the various interactions. One exemplaryimplementation of the controller is described below in more detail withreference to FIG. 6.

[0069] Upon receiving a request, the controller 406 invokes thecorresponding interaction of the program 402 to perform the behavior andreturn a view so that subsequent requests of the program can be made.The do-create-asset interaction 420, for example, is invoked after auser specifies the values of the attributes of a new asset to be addedto the asset catalog. Each interaction is defined by a series of one ormore command definitions and a view definition. Each command definitiondefines a command (e.g., object class) that provides a certain behavior.For instance, the do-create-asset interaction 420 includes five commanddefinitions-application context 430, begin transaction 432, composeasset 434, store object 436, and end transaction 438—and a viewdefinition named view asset 440.

[0070] When the do-create-asset interaction 420 is invoked, theapplication context command 430 retrieves the current applicationcontext of the application. The application context may be used by theinteraction to access certain application-wide information. The begintransaction command 432 indicates that a transaction for the assetcatalog is beginning. The compose asset command 434 creates an objectthat identifies the value of the attributes of the asset to be added tothe asset catalog. The store object command 436 stores an entryidentified by the created object in the asset catalog. The endtransaction command 438 indicates that the transaction to the assetcatalog has ended. The view asset view 440 prepares a response (e.g.,display page) to return to the user.

[0071] The attribute store 404 contains an entry for each attribute thathas been defined by any interaction of the application that has beeninvoked. The attribute store identifies a name of the attribute, a typeof the attribute, a scope of the attribute, and a current value of theattribute. For example, the last entry in the attribute store 404 hasthe name of “assetPrice”, with a type of “integer”, a value of“500,000”, and a scope of “interaction”. The scope of an attributeindicates the attribute's life. An attribute with the scope of“interaction” (also known as “request”) has a life only within theinteraction in which it is defined. An attribute with the scope of“session” has a life only within the current session (e.g., logonsession) of the application. An attribute with the scope of“application” has life throughout the duration of an application.

[0072] When the program controller 406 receives a request to create anasset (e.g., a do-create-asset request), the controller invokes thedo-create-asset interaction 420. The controller first instantiates anapplication context object defined in the interaction command 430 andprepares the object by setting its attributes based on the currentvalues of the attribute store 404. The controller then performs thebehavior of the object by invoking a perform method of the object andextracts the attribute values of the object by getting the attributevalues and storing them in the attribute store 404.

[0073] Next, the program controller 406 instantiates a begin transactionobject defined by the interaction command 432 and prepares the object bysetting its attribute values based on the current values of theattribute store 404. It then performs the behavior of the object byinvoking a perform method of the object and extracts the attributevalues of the object by getting the attribute values and storing them inthe attribute store. The controller 406 repeats this process for acompose-asset object instantiated according to command 434, thestore-object object instantiated according to command 436, and the endtransaction object instantiated according to command 438. The controller406 then invokes the view asset 440 to retrieve the values of theattributes of the asset from the attribute store 404 for purposes ofpresenting those attribute values back to the client.

[0074]FIG. 5 shows a process 500 implemented by the program controller406 of the execution model 230 when executing an interaction-basedprogram, such as program 402. The process 500 is implemented in softwareand hence, the illustrated blocks represent computer-readableinstructions, that when executed at the server system 106, perform thestated acts.

[0075] At block 502, the controller 406 sets the attribute values fromthe request in the attribute store 404. For example, a view-assetrequest may include a value for an “assetID” attribute that uniquelyidentifies an asset currently stored in the asset catalog. Thecontroller then loops through each command of the interaction associatedwith the request. At block 504, the controller selects the next commandof the interaction associated with the request, starting with the firstcommand. If all commands have already been selected (i.e., the “yes”branch from block 506), the controller 406 processes the view defined inthe view definition of the interaction and returns the response to thepresentation layer 212 (i.e., block 508).

[0076] On the other hand, if not all of the commands have been selected(i.e., the “no” branch from block 506), the controller instantiates anobject associated with the selected command (i.e., block 510). Theobject class associated with the command is specified in the commanddefinition of the interaction. In block 512, the controller 406 preparesthe object by retrieving the values of the input attributes of theobject from the attribute store 404 and invoking the set methods of theobject to set the values of the attributes. At block 514, the controllerinvokes a validate method of the object to determine whether the currentvalues of the input attributes of the object will allow the behavior ofthe object to be performed correctly. If the validate method indicatesthat the behavior cannot be performed, the controller generates anexception and skips further processing of the commands of theinteraction.

[0077] At block 516, the controller optionally invokes a security checkmethod of the object to determine whether the user that initiated therequest is able to perform the action with the object that is indicatedby the interaction. The security check method invokes the securitypolicy enforcement 280 of FIG. 2 to perform the security check. Theresult of the security check is then returned to the security checkmethod of the object, which returns the result to the controller 406.

[0078] At block 518, the controller invokes the perform method of theobject to perform the behavior of the object. At block 520, thecontroller extracts the values of the output attribute of the object byinvoking the get methods of the object and setting the values of thecorresponding attributes in the attribute store 404. The controller thenloops to block 504 to select the next command of the interaction.

[0079]FIG. 6 shows one exemplary implementation of the controller 406 inmore detail. It includes multiple components that are configuredaccording to the request-response model where individual componentsreceive a request and return a response. The controller 406 includes aservice component 602 that is invoked to service a request message. Theservice component 602 stores the value of any attributes specified inthe request in the attribute store 404. For example, the component mayset the current value of a URL attribute as indicated by the request.Once the attribute values are stored, the service component 602 invokesa handle interaction component 604 and passes on the request. It isnoted that the service component will eventually receive a response inreturn from the handle interaction component 604, which will then bepassed back to the presentation layer 212 for construction of a reply tobe returned to the client.

[0080] The handle interaction component 604 retrieves, from the programdatabase, the interaction definition for the interaction specified inthe request. The handle interaction component 604 then invokes a processinteraction component 606 and passes the request, response, and theinteraction definition.

[0081] The process interaction component 606 processes each command andview of the interaction and returns a response. For a given descriptor(i.e., command, view, or conditional) specified in the interaction, theprocess interaction component identifies the descriptor and invokes anappropriate component for processing. If the descriptor is a command,the process interaction component 606 invokes a process commandcomponent 608 to process the command of interaction. If the descriptoris a view, the process interaction component 606 invokes a process viewcomponent 610 to process the view of the interaction. If the descriptoris a conditional, the process interaction component 606 invokes aprocess conditional component 612 to process the conditional of theinteraction.

[0082] When processing a command, the process command component 608instantiates the object (e.g., as a “Java bean” in the Java™environment) for the command and initializes the instantiated object byinvoking an initialization method of the object. The process commandcomponent invokes a translator component 614 and passes the instantiatedobject to prepare the object for performing its behavior. A translatorcomponent is an object that provides a prepare method and an extractmethod for processing an object instantiated by the process commandcomponent to perform the command. Each command may specify thetranslator that is to be used for that command. If the command does notspecify a translator, a default translator is used.

[0083] The translator component 614 sets the attribute values of thepassed object based on the current attribute values in the attributestore 404. The translator component 614 identifies any set methods ofthe object based on a class definition of the object. The classdefinition may be retrieved from a class database or using a methodprovided by the object itself. When a set method is identified, thetranslator component identifies a value of the attribute associated witha set method of the object. The attribute store is checked to determinewhether a current value for the attribute of the set method is defined.If the current value of the attribute is defined in the attribute store,the attribute value is retrieved from the attribute store, givingpriority to the command definition and then to increasing scope (i.e.,interaction, session, and then application). The component performs anynecessary translation of the attribute value, such as converting aninteger representation of the number to a string representation, andpasses back the translated value. When all methods have been examined,the translator component 614 returns control to the process commandcomponent 608.

[0084] The process command component 608 may also validate the object.If valid, the component performs the behavior of the object by invokingthe perform method of the object. The component once again invokes thetranslator and passes the object to extract the attribute values of theobject and store the current attribute values in the attribute store404.

[0085] When processing a view, the process view component 610 eitherinvokes a target (e.g., JSP, ASP, etc.) or invokes the behavior of anobject that it instantiates. If a class name is not specified in thedefinition of the view, the process view component 610 retrieves atarget specified in the view definition and dispatches a view request tothe retrieved target. Otherwise, if a class name is specified, theprocess view component 610 performs the behavior of an object that itinstantiates. The process view component 610 retrieves a translator forthe view and instantiates an object of the type specified in the viewdefinition. The process view component 610 initializes the object andinvokes the translator to prepare the object by setting the values ofthe attributes of the object based on the attribute store. The processview component 610 validates the object and performs the behavior of theobject. The process view component 610 then returns.

[0086] When processing a conditional, the process conditional component612 interprets a condition to identify the descriptors that should beprocessed. The component may interpret the condition based on thecurrent values of the attributes in the attribute store. Then, theprocess conditional component 612 recursively invokes the processinteraction component 606 to process the descriptors (command, view, orconditional) associated with the condition. The process conditionalcomponent 612 then returns.

[0087] One exemplary form of a program implemented as a document typedefinition (DTD) is illustrated in Table 1. The interactions definingthe program are specified in an XML (“extensible Markup Language”) file.TABLE 1 1. <!ELEMENT program (translator*,command*,view*,interaction*)>2. <!ATTLIST program 3.  name   ID  #REQUIRED 4. > 5. 6. <!ELEMENTtranslator EMPTY> 7. <!ATTLIST translator 8.  name   ID  #REQUIRED 9. class  CDATA #REQUIRED 10.  default  (true|false) “false” 11. > 12. 13.<!ELEMENT translator-ref EMPTY> 14. <!ATTLIST translator-ref 15.  name  IDREF #REQUIRED 16. > 17. 18. <!ELEMENT command (translator-ref*,attribute*)> 19. <!ATTLIST command 20.  name   ID  #REQUIRED 21.  class CDATA #REQUIRED 22. > 23. 24. <!ELEMENT command-ref (attribute*)> 25.<!ATTLIST command-ref 26.  name   IDREF #REQUIRED 27.  type (default|finally) “default” 28. > 29. 30. <!ELEMENT attribute EMPTY>31. <!ATTLIST attribute 32.  name   ID  #REQUIRED 33.  value  CDATA#IMPLIED 34.  get-name  CDATA #IMPLIED 35.  set-name  CDATA #IMPLIED 36. scope  (application|request|session) “request” 37. > 38. 39. <!ELEMENTview> 40. <!ATTLIST view 41.  name   ID #REQUIRED 42.  target  CDATA#REQUIRED 43.  type   (default|error) “default” 44.  default (true|false) “false” 45. > 46. 47. <!ELEMENT view-ref> 48. <!ATTLISTview-ref 49.  name   IDREF #REQUIRED 50. > 51. 52. <!ELEMENT if(#PCDATA)> 53. <!ELEMENT elsif (#PCDATA)> 54. <!ELEMENT else EMPTY> 55.<!ELEMENT conditional (if?, elsif*, else*, command-ref*, view-ref*,conditional*)> 56. 57. !ELEMENT interaction(command-ref*,view-ref*,conditional*)> 58. <!ATTLIST interaction 59. name   ID  #REQUIRED 60. >

[0088] Lines 1-4 define an program tag, which is the root tag of the XMLfile. The program tag can include translator, command, view, andinteraction tags. The program tag includes a name attribute thatspecifies the name of the program. Lines 6-11 define a translator tag ofthe translator, such as translator 614. The name attribute of thetranslator tag is a logical name used by a command tag to specify thetranslator for that command. The class attribute of the translator tagidentifies the class for the translator object. The default attribute ofthe translator tag indicates whether this translator is the default 110translator that is used when a command does not specify a translator.

[0089] Lines 13-16 define a translator-ref tag that is used in a commandtag to refer back to the translator to be used with the command. Thename attribute of the translator-ref tag identifies the name of thetranslator to be used by the command. Lines 18-22 define a command tag,which may include translator-ref tags and attribute tags. Thetranslator-ref tags specify names of the translators to be used by thiscommand and the attribute tags specify information relating toattributes of the command. The name attribute of the command tagprovides the name of the command. The class attribute of the command tagprovides the name of the object class that provides the behavior of thecommand.

[0090] Lines 24-28 define a command-ref tag that is used by aninteraction tag (defined below) to specify the commands within theinteraction. The command reference tag may include attribute tags. Thename attribute of the command-ref tag specifies the logical name of thecommand as specified in a command tag. The type attribute of thecommand-ref tag specifies whether the command should be performed evenif an exception occurs earlier in the interaction. The value of“finally.” means that the command should be performed.

[0091] Lines 30-37 define an attribute tag, which stipulates howattributes of the command are processed. The name attribute of theattribute tag specifies the name of an attribute. The value attribute ofthe attribute tag specifies a value for the attribute. That value is tobe used when the command is invoked to override the current value forthat attribute in the attribute store. The get-name attribute of theattribute tag specifies an alternate name for the attribute when gettingan attribute value. The set-name attribute of the attribute tagspecifies an alternate name for the attribute when setting an attributevalue. The scope attribute of the attribute tag specifies whether thescope of the attribute is application, request (or interaction), orsession.

[0092] Lines 39-45 define a view tag that stipulates a view. The nameattribute of the view tag specifies the name of the view. The targetattribute of a view tag specifies the JSP target of a view. The typeattribute of the view tag specifies whether the view should be invokedwhen there is an error. The default attribute of the view tag specifieswhether this view is the default view that is used when an interactiondoes not explicitly specify a view.

[0093] Lines 47-50 define a view-ref tag, which is included ininteraction tags to specify that the associated view is to be includedin the interaction. The name attribute of the view-ref tag specifies thename of the referenced view as indicated in a view tag. Lines 52-55define tags used for conditional analysis of commands or views. Aconditional tag may include an “if” tag, an “else if” tag, an “else”tag, a command-ref tag, a view-ref tag, and a conditional tag. The dataof the “if” tag and the “else if” tag specify a condition (e.g., basedon attribute values in the attribute store) that defines the commands orview that are to be conditionally performed when executing interaction.

[0094] Lines 57-60 define an interaction tag, which defines a sequenceof command, view, or conditional tags of an interaction. The interactiontag may include command-ref, view-ref and conditional tags. The nameattribute of the interaction tag identifies the name of the interaction.The requests passed into the execution model specify the name of theinteraction to execute.

[0095] Table 2 provides an example XML file for the asset catalogprogram 402 illustrated in FIG. 4 and described above. Line 1 includes aprogram tag with the name of the program “asset catalog”. Lines 2-3specify the default translator for the program. Lines 5-11 define thevarious commands associated with the program. For example, as indicatedby line 7, the command named “login” is associated with the class“demo.cb.Login.” Whenever a login command is performed, an object ofclass “demo.cb.Login” is used to provide the behavior.

[0096] Lines 13-20 define the views of the program. For example, line 14illustrates that the view named “view-asset” (i.e., view 440 in FIG. 4)is invoked by invoking the target named “html/view-asset.jsp.” Lines23-119 define the various interactions that compose the program. Forexample, lines 42-53 define the view-asset interaction 416 as includingcommand-ref tags for each command defined in the interaction. Theconditional tag at lines 47-52 defines a conditional view such that if alogin user has administrator permission, the “view-asset-admin” view isinvoked; otherwise, the “view-asset” view is invoked. Lines 88-90illustrate the use of an attribute tag used within a command tag. Theattribute tag indicates that the attribute named “object” is an inputattribute of the command that corresponds to the attribute named “asset”in the attribute store 404. TABLE 2 1. <program name=“asset catalog”> 2.<translator name=“default-trans”class=“com.ge.dialect.cb.DefaultTranslator” 3. default=“true”/> 4. 5.<command name=“app-ctx” class=“demo.cb.AppCtx”/> 6. <commandname=“begin-tx” class=“demo.cb.BeginTx ”/> 7. <command name=“login”class=“demo.cb.Login”/> 8. <command name=“load-asset”class=“demo.cb.LoadAsset”/> 9. <command name=“compose-asset”class=“demo.cb.ComposeAsset”/> 10. <command name=“store-object”class=“demo.cb.StoreObject”/> 11. <command name=“end-tx”class=“demo.cb.EndTx”/> 12. 13. <view name=“error-view”target=“html/error.jsp” type=“error” default=“true”/> 14. <viewname=“view-asset” target=“html/view-asset.jsp”/> 15. <viewname=“view-asset-admin” target=“html/view-asset-admin.jsp”/> 16. <viewname=“create-asset” target=“html/create-asset.jsp”/> 17. <viewname=“modify-asset” target=“html/modify-asset.jsp”/> 18. <viewname=“login” target=”html/login.jsp”/> 19. <view name=“login-error”target=“html/login.jsp” type=“error”/> 20. <view name=“main-menu”target=“html/main-menu.jsp”/> 21. 22. 23. <interaction name=“login”> 24. <view-ref name=“login”/> 25. </interaction> 26. 27. <interactionname=“do-login”> 28.  <command-ref name=“app-ctx”/> 29.  <command-refname=“begin-tx”/> 30.  <command-ref name=“login”> 31.   <attributename=“loginUser” scope=“session”/> 32.  <command-ref> 33.  <command-refname=“end-tx” type=“finally”/> 34.  <view-ref name=“main-menu”/> 35. <view-ref name=“login-error”/> 36. </interaction> 37. 38. <interactionname=“main-menu”> 39.  <view-ref name=“main-menu”/> 40. </interaction>41. 42. <interaction name=“view-asset”> 43.  <command-refname=“app-ctx”/> 44.  <command-ref name=“begin-tx”/> 45.  <command-refname=“load-asset”/> 46.  <command-ref name=“end-tx” type=“finally”/> 47. <conditional> 48.   <if>(loginUser != void) &amp;&amp;loginUser.hasPermission(“admin”)</if> 49.    <view-refname=“view-asset-admin”/> 50.   <else/> 51.    <view-refname=“view-asset”/> 52.  </conditional> 53. </interaction> 54. 55.<interaction name=“create-asset”> 56.  <view-ref name=“create-asset”/>57. </interaction> 58. 59. <interaction name=“do-create-asset”> 60. <command-ref name=“app-ctx”/> 61.  <command-ref name=“begin-tx”/> 62. <command-ref name=“compose-asset”/> 63.  <command-refname=“store-object”> 64.   <attribute name=“object” get-name=“asset”/>65.  </command-ref> 66.  <command-ref name=“end-tx” type=“finally”/> 67. <conditional> 68.   <if>(loginUser != void) &amp;&amp;loginUser.hasPermission(“admin”)</if> 69.    <view-refname=“view-asset-admin”/> 70.   <else/> 71.    <view-refname=“view-asset”/> 72.  </conditional> 73. </interaction> 74. 75.<interaction name=“modify-asset”> 76.  <command-ref name=“app-ctx”/> 77. <command-ref name=“begin-tx”/> 78.  <command-ref name=“load-asset”/>79.  <command-ref name=“end-tx” type=“finally”/> 80.  <view-refname=“modify-asset”/> 81. </interaction> 82. 83. <interactionname=“do-modify-asset”> 84.  <command-ref name=“app-ctx”/> 85. <command-ref name=“begin-tx”/> 86.  <command-ref name=“load-asset”/>87.  <command-ref name=“compose-asset”/> 88.  <command-refname=“store-object”> 89.   <attribute name=“object” get-name=“asset”/>90.  </command-ref> 91.  <command-ref name=“end-tx” type=“finally”/> 92. <conditional> 93.   <if>(loginUser != void) &amp;&amp;loginUser.hasPermission(“admin”)</if> 94.    <view-refname=“view-asset-admin”/> 95.   <else/> 96.    <view-refname=“view-asset”/> 97.  </conditional> 98. </interaction> 99. 100. 101.<interaction name=“view-error2”> 102.  <conditional> 103. <if>“A”.equals(“B”)</if> 104.   <command-ref name=“begin-tx”/> 105.  <command-ref name=“load-asset”/> 106.   <command-ref name=“end-tx”type=“finally”/> 107.  <elsif>“NEVER”.equals(“EQUAL”)</elsif> 108.  <command-ref name=“load-asset”/> 109.   <command-ref name=“end-tx”type=“finally”/> 110.  </conditional> 111.   <view-refname=“view-asset”/> 112. </interaction> 113. 114. 115. <interactionname=“view-error”> 116.  <command-ref name=“load-asset”/> 117. <command-ref name=“end-tx” type=“finally”/> 118.  <view-refname=“view-asset”/> 119. </interaction> 120. 121. </program>

[0097] Security Enforcement Model

[0098]FIG. 7 illustrates one exemplary implementation of the securitypolicy enforcement 280 of FIG. 2. The security policy enforcement 280includes a policy enforcer 702 having a set of one or more rules 704, arule comparator 706, a control module 708, and one or more interfaces710. The policy enforcer 702 can be implemented in a variety ofdifferent manners, such as an object, a set of remotely callablefunctions or procedures, and so forth.

[0099] Generally, the policy enforcer 702 receives a user indication 712and an item indication 714 via the interface 710, along with anindication of the type of security operation/check requested by thecalling component (e.g., business logic layer 204). The user indication712 identifies the user that is making the request that resulted in thesecurity operation (e.g., the user currently logged into the applicationas identified by a user ID in the attribute store 404 of FIG. 4). Theitem indication 714 identifies the item that the identified user istrying to access that resulted in the security operation. The items thata user may attempt to access can vary by application (e.g., an asset ina database, a customer's loan information, another user's logon id orpassword, etc.).

[0100] Depending on the nature of the user indication, the controlmodule 708 may access the business logic layer 204 of FIG. 2 foradditional information regarding the requested security operation. Therule comparator 706 compares the received user and item indications 712and 714 to the rules 704 to determine whether a rule indicates therequested security operation should pass or fail. Any additionalinformation received by the control module 708 from the business logiclayer 204 may also be compared to the rules 704, or the additionalinformation may identify other checks to be performed. The comparator706 then returns a result of the security operation (e.g., a pass orfail indication) to the component that requested the security operation(e.g., the business logic layer 204). The results of a failed or passedsecurity operation are then dependent on the calling component.

[0101]FIG. 8 illustrates an exemplary method 800 of expressing securityrules. Initially, a set of high-level permission concepts 802 aredefined. In the discussions herein, the high-level permission concepts802 are referred to as the “context” and the “operation”. The operationidentifies a particular operation or action that may be defined (e.g.,creation, deletion, modification, etc.) and the context identifies whata corresponding operation may be performed on (e.g., a user object, anasset object, etc.). Based on these high-level permission concepts 802,multiple security rules 804(1), 804(2), . . . , 804(S) can be definedthat are specific to a particular application domain or business logic.These defined rules 804 are then used as the rules 704 of FIG. 7.

[0102] Returning to FIG. 7, the policy enforcer 702 can be invoked toperform a security operation by a variety of different components. Inone implementation, the program controller 406 of FIG. 4 invokes asecurity check method of an instantiated object and identifies the userobject to the security check method. The invoked security check methodthen invokes the policy enforcer 702, passing the user object (asindication 712) as well as an indication of the object that therequested operation affects (as indication 714), such as an asset in adatabase to the policy enforcer 702.

[0103] Alternatively, the policy enforcer 702 may be invoked in othermanners, such as by another component interacting with or managingobjects (e.g., the program controller 406 of FIG. 4). In some situationsthe indication of the object is inherent in the invocation of the policyenforcer 702 and only the user indication 712 need be explicitly passedto the policy enforcer 702. For example, an object may invoke the policyenforcer 702 for a security operation to determine whether a particularuser (represented by a user object) is able to access the objectinvoking the policy enforcer. In this example, the item indication isimplicitly passed to the policy enforcer 702 by nature of its beinginvoked by another object.

[0104] The interface 710 provides multiple different interfaces ormethods that can be used to invoke one of multiple different securityoperations of the policy enforcer 702. Each interface receives anindication of the user and the item corresponding to the requestedsecurity operation. In one implementation, multiple sets of interfacesare provided by the interface 710: one set that is invoked by acomponent where the item indication is implicit, and another set that isinvoked by a component where the item indication is explicitlyidentified. An exemplary interface 710 provides the following fivedifferent interfaces or methods: canBeApprovedBy, canBeCreatedBy,canBeDeletedBy, canBeModifiedBy, and canBeViewedBy.

[0105] The canBeApprovedBy method tests whether the identified item canbe approved by the specified user. For example, approval typicallyhappens for entities such as quotes or orders where a supervisorapproves or rejects an action taken by other personnel or throughautomated processes. The rules which determine whether an item can beapproved by a particular user can be arbitrary and partially based onother information available in the business logic other than the itemand the user. The canBeApprovedBy method returns true (pass) if the usercan approve or reject an action taken on the object or false (fail) ifthe user cannot perform those actions.

[0106] The canBeCreatedBy method tests whether the identified item ofthe specified type (e.g., class) can be created by the specified user.This method is used when testing whether or not a user can create acertain type of persistent item (e.g., a persistent object). Persistentitems are those that are stored into a database or other type oflong-term storage for future retrieval. The business rules whichdetermine whether an item can be created by a particular user can bearbitrary and partially based on other information available in thebusiness logic other than the item and the user. The canBeCreatedBymethod returns true (pass) if the user can create the item in question,false (fail) otherwise.

[0107] The canBeDeletedBy method tests whether the identified item canbe deleted (destroyed) by the specified user. This method is used whentesting whether or not a user can delete an individual persistent item.The business rules which determine whether an item can be deleted by aparticular user can be arbitrary and partially based on otherinformation available in the business logic other than the object andthe user. The canBeDeletedBy method returns true (pass) if the user candelete the item in question, false (fail) otherwise.

[0108] The canBeModifiedBy method tests whether the identified item canbe modified (changed) by the specified user. This method is used whentesting whether or not a user can modify an individual persistent item.The business rules which determine whether an item can be modified by aparticular user can be arbitrary and partially based on otherinformation available in the business logic other than the item and theuser. The canBeModifiedBy method returns true (pass) if the user canmodify the item in question, false (fail) otherwise.

[0109] The canBeViewedBy method tests whether a user can examine thedetails of a particular item. The business rules which determine that agiven item may be examined by the specific user can be arbitrary andpartially based on other information available in the business logicother than the item and the user. The canBeViewedBy method returns true(pass) if the user can view the contents of the item in question, false(fail) otherwise.

[0110] When a security operation is requested, the policy enforcer 702uses one or more of the rules 704 to determine whether to respond to therequest with a pass or fail result. Each of the rules 704 is referred toas a permission assignment object 716, serving to assign one or moreparticular permissions to a particular user or group of users. Multiplesuch permission assignment objects 716(1), . . . , 716(P) can beincluded in the rules 704.

[0111] Each permission assignment object 716 includes a user field 718,a role field 720, a permission (grant/deny) field 722, and a durationfield 724. The user field 718 identifies a particular user or group ofusers for which the permission assignment object 716 identifiespermissions. The role field 720 identifies a set of one or morepermissions, allowing multiple permissions to be grouped together undera single identifier. The role field 720 includes two or more additionalfields: a name field 726 and a set of one or more permission fields728(1), . . . , 728(R). The name field 726 is an identifier of theassociated set of permissions 728. Each permission field 728 includestwo additional fields to define a particular permission: a context field730 and an operation field 732. The operation field 732 identifies aparticular operation (e.g., creation, deletion, modification, etc.) andthe context field 730 identifies what that particular operation isperformed on (e.g., a user object, an asset object, etc.).Alternatively, the role field 720 may contain an individual permission(just a field 728) rather than a role (a name field 726 and permissionfield(s) 728).

[0112] The grant/deny field 722 of the permission assignment object 716identifies whether the permission(s) identified in the role field 720are granted or denied to the user identified in the user field 718. Theduration field 724 identifies a time or duration associated with thepermission(s) granted or denied by the permission assignment object 716.The time or duration may be specified in a variety of manners (e.g., astart time/date and a number of hours/days/months/etc. from the starttime/date that the permission(s) are to last, an ending time/date pastwhich the permission(s) are no longer to be applied, an indication thatthere is no time at which the permission(s) expire, and so forth).

[0113] The particular rules 704 that are included in the policy enforcer702 vary by business logic. Thus, if a designer wishes to applydifferent rules because of a change in the business logic, the policyenforcer 702 can simply be swapped out with the new policy enforcer 702including the new desired rules. The manner in which the policy enforcer702 is invoked does not change, nor does the permission concept ofdefining permissions as contexts and operations. The underlying data inthose specific permissions changes, but not the permission concepts.

[0114] The fields 716-732 may include the actual data for theinformation they represent or alternatively a pointer to the data. Usinga pointer allows, for example, the same permission 728 to be identifiedmultiple different permission assignment objects 716 and/or multipledifferent roles 720 without duplicating storage of the data of thepermission 728 for each object and/or role.

[0115] An example set of permissions and associated roles can be seen inTables 3 and 4 below. These can be used to assign permissions toparticular users and/or groups of users by the system designer as he orshe chooses. Table 3 describes the various defined permissions, whileTable 4 identifies which role(s) the permissions are associated with (an“x” in a cell of Table 4 indicates that the identified permission isassociated with the identified role). These permissions and roles are anexample set that can be used in an asset sales domain, allowing clientsto purchase and sell assets. A permission name is included foridentification purposes, though it need not be stored in the rules 704(and is not stored in the rules 704 in the illustrated example of FIG.7). TABLE 3 Permission Name Context Operation Description External AssetExternal Search publicly available assets Search Search Asset InternalAsset Internal Search private assets Search Own Search owned byrequestor's Asset Own organization. Additional requirement: The objectwas created by the requestor (Object.getCreatedBy( ) == User.getID( )).Internal Asset Internal Search all private assets Search All Search AllAsset Create Asset Asset Create Create assets Externalize Asset Exter-Make an asset publicly available Asset nalize Modify Asset Modify Modifyany asset Asset Asset View Asset Asset View View any asset Delete AssetAsset Delete Delete assets View My Quote View Own Quotes requested byme, Quote created by me or created for me. Additional requirements: theobject was created by me (Object.getCreatedBy( ) == User.getID( )), andcreated for me (Object.getCreatedFor( ) == User.getID( )). View AllQuote View All View all quotes Quote Respond Quote Respond Respond to aquote Quote Search For Quote Search Search for quotes requested by MyQuote Own me, created by me or created for me Search For Quote SearchAll Search for all quotes All Quote Delete Quote Delete Delete any quoteQuote See Quote Quote See See all quote reports Reports Reports RequestFor Quote Request Create a request for quote Quote For Create QuoteCreate Create quote Quote Modify Quote Modify Modify any quote QuoteCreate User User Create Create user Modify User User Modify Modify anyuser. May not alter any user that has System Administration permission.Disable User Disable Disable user User Delete user User Delete Deleteuser. May not alter any user that has System Administration permission.May only delete users if and only if User ID not a foreign key referencein Assets and Quotes. Modify My User Modify Modify own User information(except Info Own permission levels and organization affinity) Create ADPADP Create Create ADP customer Customer Cus- tomer Search ADP ADP SearchSearch for ADP customer Customer Cus- tomer Modify ADP Modify Modify anADP customer ADP Cus- Customer tomer Delete ADP ADP Delete Delete ADPcustomer Customer Cus- tomer System * * System administration Adminprivileges. System administrators can perform all other operations.

[0116] TABLE 4 Sales Admin Internal Force ADP User Permission Name Role?Role? Role? Role? Role? External Search Asset x x x x x Internal SearchOwn Asset x x Internal Search All Asset x x x Create Asset x xExternalize Asset x x Modify Asset x x View Asset x x x x x Delete Assetx View My Quote x x x x x View All Quote x x x Respond Quote x x xSearch For My Quote x x x x x Search For All Quote x x x Delete Quote xx See Quote Reports x Request For Quote x x x x x Create Quote x xModify Quote x x Create User x Modify User x Disable User x Delete Userx Modify My Info x x x x x Create ADP Customer x Search ADP Customer xModify ADP Customer x Delete ADP Customer x System Administration

[0117] The rule comparator 706 uses the rules 704 to determine whatresult to return in response to a requested security operation. Therules 704 can be interpreted as permissive (the default is that thesecurity operation fails unless a rule indicates that it shouldsucceed/pass), or alternatively as impermissive (the default is that thesecurity operation succeeds/passes unless a rule indicates that itshould fail). For example, assume that a user having an identifier of“Joe” desires to modify an asset. The policy enforcer 702 receives asecurity operation request to return a result indicating whether userJoe is able to modify the asset. The rule comparator 706 checks therules 704 to determine whether there is any rule that grants user Joepermission to modify the asset. Referring to Tables 3 and 4, if a rulehas been created that user Joe is granted permission to modify any asset(“Modify Asset” in Tables 3 and 4), such as assigning user Joe to the“Admin” or “Internal” roles, then the requested security operationsucceeds/passes (otherwise, it fails).

[0118] Additionally, situations can arise where additional informationis used by the policy enforcer to determine the result for a securityoperation. In these situations, the control module 708 communicates withthe business logic layer 204 to determine what additional tests orcomparisons need to be performed in order to obtain the result of thesecurity operation. These may be additional comparisons required by therule comparator 706, or alternatively additional instructions executedby the control module 708. For example, the Internal Search Own Assetpermission in Tables 3 and 4 indicate that in order for the securityoperation to succeed the user ID (e.g., “Joe”) indicated in the securityoperation request must be the same as the user ID of the user thatcreated the item. This additional check can be performed by the controlmodule 708, such as querying the item via a “getCreatedBy” interface onthe item that causes the item to return the user ID of its creator. Thisadditional check may also involve additional communication with thebusiness logic layer 204. For example, the business logic layer 204 mayinclude objects or other modules to return the creator of the item. Byway of another example, the Modify User permission in Tables 3 and 4indicate that in order for the security operation to succeed, the userobject cannot be altered if it has System Administration permission.

[0119] Which security operations use additional information from thebusiness logic can be identified in different manners. In oneimplementation, they are flagged in or coded into the control module 708so that each time the security operation is invoked the control module708 knows to access the business logic for the additional information.Alternatively, control module 708 may communicate with the businesslogic for each security operation and receive an indication from thebusiness logic of either the additional information or an indicationthat there is no additional information.

[0120] If additional tests are to be carried out by the control module708, then those can be carried out prior to, subsequent to, orconcurrently with the rule comparison performed by the rule comparator706. This can result, in some situations, in the rule comparator 706 notneeding to perform any rule comparison. For example, if the user ID(e.g., “Joe”) indicated in the security operation request must be thesame as the user ID of the user that created the item in order for thesecurity operation to succeed, and if the control module 708 determinesthat the two user IDs are not the same, then the rule comparator 706need not check any of the rules 704 because it knows that, regardless ofthe rules 704, the result of the requested security operation is a fail.

[0121] Although only a single policy enforcer 702 is illustrated in FIG.7, alternatively multiple policy enforcers 702 may be activesimultaneously. The work can be distributed among multiple policyenforcers in a variety of different manners, such as where each requestfor security rule validation is processed by a particular policyenforcer depending upon the context of the request, the type ofoperation of the request, and so on.

[0122] The security policy enforcement 280 uses a layered approach thatallows application developers to utilize readily understood securityrules. These rules are defined in high-level concepts that are easilyunderstood and used by developers. The rules are then mapped to specificbusiness logic by the policy enforcer 702, which interprets thehigh-level terms in the context of specific business logic appropriateto the given application. This mapping and the business logic can easilybe swapped out or tuned for specific instances and new mappings orbusiness logic plugged in while allowing the application to continue touse the same high level constructs to reference the security rules. Newsecurity rules and business logic can be easily created for newapplications whether in a similar problem domain or a new problemdomain, and plugged into the architecture 110 as a new security policyenforcement 280. Additionally, the application can be developed rapidlyutilizing the easily defined high-level rules only—the business logicneed not be implemented right away. Thus, implementation can easily bedone in such a manner that its delay will not hinder higher levelapplication developers. Furthermore, this layered approach allowsvarying granularities of access control to be attained using onemechanism.

[0123]FIG. 9 shows a general operation 900 of the security policyenforcement 280 of FIG. 2. The operation 900 is implemented as asoftware process of acts performed by execution of softwareinstructions. Accordingly, the blocks illustrated in FIG. 9 representcomputer-readable instructions, that when executed at the server system106 of FIG. 1, perform the acts stipulated in the blocks. FIG. 9 isdiscussed with additional reference to elements of FIG. 7.

[0124] At block 902, the interface 710 receives an indication of a user,an item, and a requested security operation type. As discussed above,the item can be explicitly or implicitly identified.

[0125] At block 904, the control module 708 checks whether additionallogic is to be used to determine whether to return a permission grant.If additional logic is to be used, then the control module 708 accessesthe business logic layer 204 of FIG. 2 to determine what that additionallogic is (block 906). At block 908, the control module 708 incorporatesthis additional logic into the operation request. This incorporation mayinvolve generating additional rule tests to be carried out by the rulecomparator 706, or alternatively additional tests to be carried out bythe control module 708.

[0126] At block 910, the rule comparator 706 accesses the rules 704corresponding to the user. At block 912, the rule comparator 706 checkswhether the rules 704 indicate that the user is permitted to perform therequested operation. If the user is not permitted to perform therequested operation, then the rule comparator 706 returns an error orrequest failure result (block 914). However, if the user is permitted toperform the requested operation, then the rule comparator 706 returns arequest permitted (or succeed/pass) indication (block 916).

CONCLUSION

[0127] The discussions herein are directed primarily to software modulesand components. Alternatively, the systems and processes describedherein can be implemented in other manners, such as firmware orhardware, or combinations of software, firmware, and hardware. By way ofexample, one or more Application Specific Integrated Circuits (ASICs) orProgrammable Logic Devices (PLDs) could be configured to implementselected components or modules discussed herein.

[0128] Although the invention has been described in language specific tostructural features and/or methodological acts, it is to be understoodthat the invention defined in the appended claims is not necessarilylimited to the specific features or acts described. Rather, the specificfeatures and acts are disclosed as exemplary forms of implementing theclaimed invention.

What is claimed is:
 1. A system comprising: a pluggable security policyenforcement module configured to be replaceable in the system and toprovide different granularities of control for a business logic in thesystem, wherein the business logic processes requests submitted to thesystem.
 2. A system as recited in claim 1, wherein the differentgranularities of control comprise a plurality of sets of rules that canbe replaced with each other without altering the business logic.
 3. Asystem as recited in claim 1, wherein the pluggable security policyenforcement module is further configured to determine, for a particulargranularity of control, whether to permit an operation, requested by auser based, based at least in part on a permission assigned to the user.4. A system as recited in claim 1, wherein the pluggable security policyenforcement module includes a control module configured to determinewhether to permit an operation based at least in part on accessing thebusiness logic to identify one or more additional tests to perform, andfurther configured to perform the one or more additional tests.
 5. Asystem as recited in claim 4, wherein the control module is furtherconfigured to return a result of the determining to the business logic.6. A system as recited in claim 1, wherein the different granularitiesof control comprise a plurality of sets of rules, and wherein each setof rules includes a plurality of permission assignment objects, whereineach of the permission assignment objects associates a user with aparticular role, wherein each particular role is associated with one ormore permissions, and wherein each of the one or more permissionsidentifies a particular operation and context on which the operation isto be performed.
 7. A system as recited in claim 6, wherein each of thepermission assignment objects further identifies whether the one or morepermissions in the particular role are granted to the user or denied tothe user.
 8. One or more computer-readable media comprisingcomputer-executable instructions that, when executed, direct a processorto perform acts including: receiving a request to perform an operation;checking whether to access a business logic in order to generate aresult for the requested operation; obtaining, from the business logic,a set of zero or more additional tests to be performed in order togenerate the result; performing each additional test in the set of testsif there is at least one test in the set of tests; checking a set ofpluggable rules to determine the result of the requested operation; andreturning, as the result, a failure indication if checking the businesslogic or checking the set of pluggable rules indicates that the resultis a failure, otherwise returning, as the result, a success indication.9. One or more computer-readable media as recited in claim 8, whereinthe receiving comprises receiving, from the business logic, the requestto perform the operation.
 10. One or more computer-readable media asrecited in claim 8, wherein the receiving comprises receiving, as partof the request, an indication of a user, and wherein the checking theset of pluggable rules comprises comparing an object associated with theuser to the rules in the set of pluggable rules and determining whetherthe operation can be performed based at least in part on whether theuser is permitted to perform the operation.
 11. One or morecomputer-readable media as recited in claim 8, wherein the receivingcomprises having one of a plurality of methods invoked.
 12. One or morecomputer-readable media as recited in claim 8, wherein the set ofpluggable rules is a set of security rules defined using high-levelpermission concepts.
 13. One or more computer-readable media as recitedin claim 12, wherein the high-level permission concepts include anoperation and a context, wherein the operation allows identification ofan operation to be performed and the context allows identification ofwhat the operation is to be performed on.
 14. One or morecomputer-readable media as recited in claim 8, wherein thecomputer-executable instructions are implemented as an object.
 15. Oneor more computer-readable media as recited in claim 8, wherein thecomputer-executable instructions further direct the processor to performacts including: determining if at least one of the tests in the set ofzero or more additional tests would indicate a result of failure; andreturning, as the result, the failure indication without checking theset of pluggable rules.
 16. One or more computer-readable media asrecited in claim 8, wherein the set of pluggable rules can be replacedwith another set of pluggable rules without altering the business logic.17. One or more computer-readable media as recited in claim 8, whereinthe set of pluggable rules includes a plurality of permission assignmentobjects, wherein each of the permission assignment objects associates auser with a particular role, wherein each particular role is associatedwith one or more permissions, and wherein each of the one or morepermissions identifies a particular operation and context on which theoperation is to be performed.
 18. One or more computer-readable media asrecited in claim 17, wherein each of the permission assignment objectsfurther identifies whether the one or more permissions in the particularrole are granted to the user or denied to the user.
 19. A methodcomprising: providing high-level permission concepts for security rules;allowing a set of security rules to be defined using the high-levelpermission concepts, wherein the set of security rules allowspermissions to be assigned to users of an application; and determining,based at least in part on a permission assigned to a user, whether topermit an operation based on a request by the user.
 20. A method asrecited in claim 19, wherein the determining further comprisesdetermining whether to permit the operation requested by the user basedat least in part on accessing a business logic to identify one or moreadditional tests to perform, and further comprising performing the oneor more additional tests.
 21. A method as recited in claim 20, furthercomprising returning a result of the determining to the business logic.22. A method as recited in claim 19, wherein the high-level permissionconcepts include an operation and a context, wherein the operationallows identification of an operation to be performed and the contextallows identification of what the operation is to be performed on.
 23. Amethod as recited in claim 19, wherein the method is implemented in anobject having a plurality of interfaces for requesting a determinationas to whether to permit a plurality of operations including theoperation requested by the user.
 24. A method as recited in claim 19,wherein the set of security rules includes a plurality of permissionassignment objects, wherein each of the permission assignment objectsassociates a user with a particular role, wherein each particular roleis associated with one or more permissions, and wherein each of the oneor more permissions identifies a particular operation and context onwhich the operation is to be performed.
 25. A method as recited in claim24, wherein each of the permission assignment objects further identifieswhether the one or more permissions in the particular role are grantedto the user or denied to the user.
 26. A method comprising: receiving arequest to perform an operation; accessing a set of low-level rules,wherein the low-level rules are defined in terms of high-level concepts;checking whether a user requesting to perform the operation is entitledto perform the operation based at least in part on the set of low-levelrules; and returning an indication of whether the operation is allowedor not allowed.
 27. A method as recited in claim 26, wherein thechecking further comprises checking whether the user is entitled toperform the operation based at least in part on accessing a businesslogic to identify one or more additional tests to perform, and furthercomprising performing the one or more additional tests.
 28. A method asrecited in claim 27, wherein the set of low-level rules can be replacedwith another set of low-level rules without altering the business logic.29. A method as recited in claim 27, further comprising returning theindication to the business logic.
 30. A method as recited in claim 26,wherein the low-level rules include a plurality of permission assignmentobjects, wherein each of the permission assignment objects associates auser with a particular role, wherein each particular role is associatedwith one or more permissions, and wherein each of the one or morepermissions identifies a particular operation and context on which theoperation is to be performed
 31. A method comprising: assigning highlevel security concepts to an application domain; and allowing a set ofpluggable rules to define low-level rules, in terms of the high levelsecurity concepts, for different business logic in the applicationdomain.
 32. A method as recited in claim 31, wherein the high levelsecurity concepts include an operation and a context that identifieswhat the operation is performed on.
 33. A method as recited in claim 31,further comprising: determining, based at least in part on a permissionassigned to a user and on one or more additional tests identified byaccessing the business logic, whether to permit an operation based on arequest by the user.
 34. A method as recited in claim 33, furthercomprising returning a result of the determining to the business logic.35. An architecture comprising: a plurality of resources; a businesslogic layer to process, based at least in part on the plurality ofresources, requests received from a client; and a pluggable securitypolicy enforcement module to enforce security restrictions on accessinginformation stored at the plurality of resources.
 36. An architecture asrecited in claim 35, wherein the pluggable security policy enforcementmodule defines high-level permission concepts for security rules andfurther defines a set of security rules using the high-level permissionconcepts.
 37. An architecture as recited in claim 36, wherein thehigh-level permission concepts include an operation and a context,wherein the operation allows identification of an operation to beperformed and the context allows identification of what the operation isto be performed on.
 38. An architecture as recited in claim 35, whereinthe pluggable security policy enforcement module can be replaced withanother pluggable security policy enforcement module to enforcedifferent security restrictions without altering the business logiclayer.
 39. An architecture as recited in claim 35, wherein the pluggablesecurity policy enforcement module is configured to determine, based atleast in part on a permission assigned to a user and on one or moreadditional tests identified by accessing the business logic layer,whether to permit an operation to access information at the plurality ofresources.